Skip to content

macOS: build a real darwin-x64 baseline - #34207

Closed
tobocop2 wants to merge 6 commits into
oven-sh:mainfrom
tobocop2:claude/darwin-x64-baseline
Closed

tobocop2 wants to merge 6 commits into
oven-sh:mainfrom
tobocop2:claude/darwin-x64-baseline

Conversation

@tobocop2

@tobocop2 tobocop2 commented Jul 15, 2026 •

Copy link
Copy Markdown

Important

Blocked by oven-sh/WebKit#290
This lane builds darwin-x64 --baseline, which downloads bun-webkit-macos-amd64-baseline.tar.gz. That artifact does not exist yet (HTTP 404) — oven-sh/WebKit#290 is what builds it.

Until WebKit#290 merges and its autobuild publishes the tarball, this PR's CI cannot go green: the new darwin baseline lane will fail to fetch its prebuilt. Ready for review on the substance; flip out of draft once the artifact exists.

Problem

@oven/bun-darwin-x64-baseline is the AVX2 build — byte-identical to the default:

ea2f223e94bb2f4bf3050895113c3cf346438f6fa0501c8532284e063f72f7a0  @oven/bun-darwin-x64
ea2f223e94bb2f4bf3050895113c3cf346438f6fa0501c8532284e063f72f7a0  @oven/bun-darwin-x64-baseline

Same file, same 69,173,328 bytes. Disassembly: 248,019 AVX2 (ymm) + 7,049 AVX-512. Identical at 1.2.20 too — not a regression.

Linux, for contrast, ships a real baseline:

9fd36f87e4b90b07632b987a2e4ec81ca15a62c81bf983190cea6d715be2ad74  @oven/bun-linux-x64           299,928 AVX2
a8f9ebd1770ddc8e55dab7a68d4ec1ec1eebf374bb97cc65cf2c3cb373fc6791  @oven/bun-linux-x64-baseline   12,328 AVX2

So a pre-AVX2 Mac gets no working bun and no fallback. Downstream: opencode#29039, opencode#24876.

Root cause

A missing build lane — not the resolution logic:

.buildkite/ci.mjs buildPlatforms linux has baseline: true; darwin has no baseline entry
packages/bun-release/src/platform.ts:41 already declares the bun-darwin-x64-baseline npm package → it ships anyway, fed the default binary
scripts/build/deps/webkit.ts prebuiltSuffix() already appends -baseline for any x64 (no OS check) → the URL was always right

The URL is right; the artifact doesn't exist:

$ curl -sIL -o /dev/null -w '%{http_code}\n' https://github.com/oven-sh/WebKit/releases/download/autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b/bun-webkit-macos-amd64.tar.gz
200
$ curl -sIL -o /dev/null -w '%{http_code}\n' https://github.com/oven-sh/WebKit/releases/download/autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b/bun-webkit-macos-amd64-baseline.tar.gz
404

Fix

The fixing line — one entry in buildPlatforms (.buildkite/ci.mjs), mirroring the linux baseline lane:

{ os: "darwin", arch: "x64", baseline: true, crossCompile: true, distro: "amazonlinux", release: "2023", features: ["docker"] },

Plus one stale comment in scripts/build/deps/webkit.ts:

- // Linux amd64 (glibc + musl) and Windows amd64. No baseline variant for
- // arm64 or macOS.
+ // Linux amd64 (glibc + musl), Windows amd64, and macOS amd64. No baseline
+ // variant for arm64 (no AVX on arm64 — baseline is x64-only).

No change to prebuiltSuffix() or CompileTarget — already correct.

Verification

Built darwin-x64 --baseline=true against a locally-produced bun-webkit-macos-amd64-baseline (WebKit's own unmodified macos-cross-release.sh + MARCH_FLAG=-march=nehalem):

libJavaScriptCore.a AVX2 (%ymm)
-march=nehalem (this) 0
shipped bun-webkit-macos-amd64 58,967

The resulting bun:

Mach-O 64-bit x86_64 executable
sha256  bede5eb3c917fa353d6b067fd7055d42774db7a7d5a09c21fa6cdd05e3d8efee
binary AVX2 (ymm)
shipped @oven/bun-darwin-x64 (== -baseline) 248,019
this baseline build 14,407
@oven/bun-linux-x64-baseline (verified on real pre-AVX2 hardware) 12,328

A baseline build isn't "zero AVX2" — the residual sits behind CPUID runtime dispatch, exactly like the linux baseline. What matters is the profile matches the linux baseline (which I verified runs on a pre-AVX2 CPU), not the AVX2 default.

On the unfixed tree the target 404s on the prebuilt — which is why no darwin baseline has ever shipped.

Recipe validated on real pre-AVX2 hardware (Sandy Bridge Xeon, AVX + SSE4.2, no AVX2/FMA): the -march=nehalem linux baseline runs there (opencode run completes); the -march=haswell build crashes (~21 s, ~3.9 GB RSS, segfault in the simdutf path).

Who this is for

Pre-Haswell Intel Macs on a macOS bun still supports.

opencode#24876:

macOS: 13.7.4 · Machine: Macmini6,2 (Intel Ivy Bridge, 2012) · CPU: x86_64 (supports AVX, but NOT AVX2)

13.7.4 clears bun's 13.0 deployment target; the CPU has no AVX2. That combination is the gap. Same reporter — who independently suggested -march=nehalem:

This makes the tool unusable on: Intel Macs pre-Haswell (≈ 2013 and earlier) … These machines are still relatively common in development environments.

opencode#29039 confirms the packaging bug from the Mach-O header itself:

otool -h shows cpusubtype 3 (CPU_SUBTYPE_X86_64_H — Haswell) for both

How they're on a current macOS: OpenCore Legacy Patcher (17.8k stars, 5,046,133 downloads on 2.4.1) runs current macOS on Macs Apple dropped, pre-Haswell included. Not all of those users are pre-AVX2 — but "old Mac, current macOS" is common, not exotic. I run it on my mom's 2013 Intel Mac; the OS is new enough for bun, the CPU isn't.

Why it's cheap

  • Infra exists: Dockerfile.macos already takes MARCH_FLAG and sets CMAKE_SYSTEM_NAME=Darwin; darwin lanes already cross-compile on Linux under docker. One lane cloned from an existing one.
  • bun already publishes bun-darwin-x64-baseline and routes non-AVX2 Macs to it. Today that resolves to a binary that can't run on the CPU it was selected for.

If a baseline macOS build isn't wanted, the coherent alternative is to stop shipping the package and state that x64 macOS requires Haswell+. Right now it's neither.

Relationship to the other PRs

This is one of four pieces; none of them alone gives pre-Haswell Mac users a working binary:

PR what it does blocks this?
oven-sh/WebKit#290 builds + publishes the Nehalem macOS WebKit (bun-webkit-macos-amd64-baseline and -baseline-lto) yes — without it the lane 404s and CI cannot go green
oven-sh/WebKit#292 makes JSC detect AVX at runtime on macOS instead of assuming it not for CI, but see below
#32512 guardrail — makes a prebuilt baseline macOS build fail loudly instead of silently linking the Haswell WebKit no
this PR adds the darwin-x64-baseline build lane once the artifact exists —

On oven-sh/WebKit#292. This lane will build and go green with #290 alone, and the resulting binary works on Sandy/Ivy Bridge — the CPUs in nearly every report on #32511/#26872. It does not work on a Mac with no AVX at all (Westmere, e.g. a Mac Pro 5,1 on OpenCore), and it does not run WebAssembly there, because JSC assumes AVX on Darwin and the JIT emits VEX regardless of -march. Both are fixed by #292.

That matters for sequencing because of what this PR is for: packages/bun-release/src/platform.ts already publishes bun-darwin-x64-baseline, and non-AVX2 Macs already resolve to it. Landing #290 + this PR without #292 turns "the baseline package is the Haswell build and crashes on every pre-Haswell Mac" into "the baseline package is real and crashes only on pre-AVX Macs" — a large improvement, but still a package that SIGILLs for some of the users it was selected for, which is the thing #32512 exists to prevent. With #292 in the pinned WebKit, the artifact does what its name says on every CPU that resolves to it.

Since both WebKit changes land in the same repo and this PR needs a WEBKIT_VERSION bump anyway (below), the cheapest ordering is: #290 + #292 merge → autobuild publishes → bump the pin here to that SHA.

#32512 names this exact sequencing:

A true baseline macOS binary requires a Nehalem macos-amd64-baseline WebKit built and published in oven-sh/WebKit. Once that artifact exists, this guard can be relaxed and a darwin/x64/baseline lane added to .buildkite/ci.mjs.

That artifact now exists and is verified — oven-sh/WebKit#290 builds it with WebKit's own unmodified macos-cross-release.sh, and its libJavaScriptCore.a has 0 %ymm instructions vs 58,967 in the shipped Haswell one.

Ordering: if #32512 lands first, this PR needs a trivial rebase to relax the baseline && darwin && webkit === "prebuilt" assert it adds — which is precisely what #32512 says should happen once the artifact exists. If this lands first, #32512's guard should be scoped to "no baseline WebKit for the pinned WEBKIT_VERSION" rather than "never for macOS".

Still needed before this can go green

  1. macOS: build a baseline (non-AVX2) x64 WebKit WebKit#290 merged and autobuilt — until then the lane 404s on the prebuilt.
  2. A WEBKIT_VERSION bump in scripts/build/deps/webkit.ts to that autobuild. The current pin (4895f45) is WebKit main HEAD today, so the bump should be workflow-only. Not included here because the target autobuild doesn't exist yet. Ideally that pin lands on a SHA containing both can't use redux with next's #290 and fetch module errors at random times #292, so the artifact this lane ships is correct on every CPU that resolves to it.

robobun's preview build on the (now closed, folded into #290) oven-sh/WebKit#291 already ran the full matrix and published bun-webkit-macos-amd64-baseline.tar.gz and -baseline-lto.tar.gz, so the lane is known to work in real CI and not just locally: https://github.com/oven-sh/WebKit/releases/tag/autobuild-preview-pr-291-45bcadc5

Also in this PR

  • testPlatforms gets a darwin-x64-baseline entry, matching the linux (debian/ubuntu/musl) and windows x64 baseline lanes. The shipped darwin baseline artifact has never been exercised by the test suite — which is how it shipped as the Haswell build unnoticed. Easy to drop if the Intel mac pool is too tight; flagged by robobun as a maintainer call.

Fixes #32511
Fixes #26872

Both report the same thing this makes possible: a bun-darwin-x64-baseline that actually runs on pre-Haswell Intel Macs. Neither is fixed until oven-sh/WebKit#290 lands too — happy to drop the Fixes keywords if you'd rather close them manually once the artifact ships.

Prebuilt artifacts from this exact recipe (this bun, plus an opencode compiled against it) for anyone with a pre-AVX2 Mac willing to test: https://github.com/tobocop2/opencode-bun-pre-avx2-mac/releases/latest

That build includes oven-sh/WebKit#292 as well, so it covers no-AVX Macs. A Mac Pro 5,1 (Xeon X5690, Westmere) confirmed an earlier build of it fixed the startup SIGILL: anomalyco/opencode#8345 (comment)

@oven/bun-darwin-x64-baseline is byte-identical to @oven/bun-darwin-x64 (the
AVX2 build), so pre-AVX2 Intel Macs get no working binary and no fallback.
buildPlatforms had no darwin baseline lane, though platform.ts already
declares the npm package and prebuiltSuffix() already requests the baseline
WebKit tarball.

Gated on oven-sh/WebKit#290, which publishes bun-webkit-macos-amd64-baseline.
@robobun

robobun commented Jul 15, 2026

Copy link
Copy Markdown
Collaborator

Two things this lane will need to go green once the WebKit artifact lands:

  1. The LTO variant. The darwin build lanes cross-compile from Linux, so ltoDefault in scripts/build/config.ts resolves to true (release && (linux || darwinCross) && ci), and prebuiltSuffix() appends -lto after -baseline. This lane will therefore fetch bun-webkit-macos-amd64-baseline-lto.tar.gz, not the plain -baseline tarball. macOS: build a baseline (non-AVX2) x64 WebKit WebKit#290 only builds the non-LTO variant, so either that PR (or Build and publish macOS amd64 baseline (-march=nehalem) artifacts WebKit#291, which includes it) needs to ship -baseline-lto, or config.ts needs darwin && baseline added to the LTO force-off alongside the existing windows cases, at the cost of shipping a non-LTO baseline binary while the default darwin-x64 is LTO.

  2. A WEBKIT_VERSION bump in scripts/build/deps/webkit.ts to an autobuild that contains the new artifacts, once the WebKit-side PR merges to main (current pinned 4895f45 is main HEAD today, so the bump should be workflow-only).

Possibly also worth adding { os: "darwin", arch: "x64", baseline: true, release: "14", tier: "latest" } to testPlatforms so the shipped baseline artifact gets the test suite run, matching the windows-x64-baseline and linux baseline lanes, though the Intel mac pool is small so that's a maintainer call.

Every other baseline artifact is covered in testPlatforms (linux x64 debian +
ubuntu, linux x64 musl alpine, windows x64). darwin x64 baseline had no entry,
so the shipped artifact was never exercised — which is how it shipped as the
Haswell build unnoticed.

Suggested by robobun in oven-sh#34207.
@tobocop2

tobocop2 commented Jul 15, 2026 •

Copy link
Copy Markdown
Author

All three are right — thanks.

  1. LTO variant — fixed in macOS: build a baseline (non-AVX2) x64 WebKit WebKit#290; it now builds -baseline and -baseline-lto. Took the lane rather than forcing LTO off. can't use redux with next's #290 also picks up your windows-amd64-baseline-lto catch.
  2. WEBKIT_VERSION bump — agreed, once can't use redux with next's #290 autobuilds. Not here; the target doesn't exist yet.
  3. testPlatforms — added. Drop it if the Intel mac pool is tight.

Re #32512: the Nehalem macOS WebKit does build, via WebKit's own unmodified macos-cross-release.sh — libJavaScriptCore.a comes out with 0 %ymm vs 58,967 in the shipped one. Not tested on a real pre-AVX2 Mac yet though; none are rentable. Builds: https://github.com/tobocop2/opencode-bun-pre-avx2-mac

@WolfgangFahl

Copy link
Copy Markdown

Cross-reporting a real-hardware test of the artifact this lane produces — Mac Pro 5,1, Xeon X5690 (Westmere, no AVX/AVX2/BMI), macOS 14.7.8. Full report + SHA-256 hashes: anomalyco/opencode#8345 (comment).

tl;dr: the WebKit -march=nehalem fix clears the startup SIGILL, but the JSC JIT still SIGILLs under real JS load.

Tested bun-darwin-x64-baseline from tobocop2/opencode-bun-pre-avx2-mac v1.18.1-baseline:

  • bun --version ✅ and bun -e 'console.log(process.stderr.fd)' ✅ — startup/bmalloc constructor path no longer crashes.
  • JIT-heavy loop let s=0;for(let i=0;i<3e7;i++)s+=Math.sqrt(i) ❌ SIGILL (exit 132) with JIT on; ✅ with BUN_JSC_useJIT=0 (interpreted).
  • opencode --version ❌ SIGILL (exit 132) — crash banner prints Features: jsc no_avx2 no_avx then CPU lacks AVX support and panics.

Heads-up for this lane: once green, a darwin-x64-baseline built this way will still pass --version CI yet crash under actual JS execution unless JSC's JIT gates AVX on the runtime CPU check — that's a separate concern from the WebKit -march=nehalem AOT fix, because the JIT emits instructions at run time regardless of the build -march. A bun --version smoke test is therefore not sufficient to certify a baseline build; a JIT-on workload is the decisive test.

Happy to re-test any updated artifact — this is a permanent no-AVX box.

(Minor: the binary self-reports Bun Canary v1.4.0-canary.1 (1e3511800), not 1.18.1.)

@tobocop2

Copy link
Copy Markdown
Author

Your heads-up was right, and it turned out to be the load-bearing point on this whole chain — thank you.

You called it precisely: the JIT emits AVX at runtime regardless of the build -march, so the Nehalem WebKit fixes startup and nothing else. The cause is MacroAssemblerX86_64.cpp assuming AVX on Darwin instead of asking the CPU. oven-sh/WebKit#292 fixes it, and I've added it to this PR's dependency table — this lane builds green with #290 alone, but the artifact it ships would still SIGILL on your X5690, which is exactly the "baseline package that isn't baseline" problem #32512 exists to prevent.

It was worse than either of us thought. The same assumption lives in a second place — JSC's probe trampoline uses vmovaps unconditionally on Darwin — and that one is reachable from WebAssembly (WasmBBQJIT loop OSR entry and tier-up, WasmOMGIRGenerator's catch prologue), with no debug flag. So a build with only the feature-detection fix still died on any WASM workload. Caught in review on #292:

build JIT loop WASM hot loop
Nehalem WebKit only (what you tested) 132 132
+ AVX runtime detection rc=0 132
+ trampoline fix (#292 as it stands) rc=0 rc=0

New build with both halves: https://github.com/tobocop2/opencode-bun-pre-avx2-mac/releases/latest

e7ede2b3f9361f6a9875f75cd79c6d0d7c90af373c290fe207a3e3a80882aa01  bun-darwin-x64-baseline
f425f035a5f00a93e1ba93d426e6687a0b58a1443b594ea75d8b35d99d11bd7f  opencode-darwin-x64-baseline

opencode --version now reports 1.18.1 rather than 0.0.0--<ts> — that was a tag clone leaving a detached HEAD, so the version derivation fell back to a preview string. The bun inside still self-reports 1.4.0-canary.1, which is honest: it's built from bun main @ 1e35118008, not from a 1.18.x tag. The release tag tracks opencode's version, not bun's.

On your testing point — agreed, and it's worth separating two things. bun's testPlatforms entries do run the real suite rather than a --version smoke test, so the lane this PR adds would have caught the JIT crash. The deeper issue is that no darwin baseline test lane existed at all, which is how a Haswell binary shipped under the baseline name unnoticed. That's why this PR adds one.

Everything above is verified under Rosetta 2 (Apple M1, macOS 14.6.1), which reports no AVX and reproduced your X5690 results exactly on the previous build — but it's emulation, not Westmere silicon. If you have time to put this one on the X5690, that's the piece I can't get: a no-AVX-at-all CPU clearing a JIT-on workload and a WASM loop.

@tobocop2
tobocop2 marked this pull request as ready for review July 17, 2026 02:35

@claude claude Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Claude Code Review

This pull request is from a fork — automated review is disabled. A repository maintainer can comment @claude review to run a one-time review.

@coderabbitai

coderabbitai Bot commented Jul 17, 2026 •

Copy link
Copy Markdown
Contributor

Review Change Stack

Walkthrough

Changes

Darwin x64 baseline alignment

Layer / File(s) Summary
Align Darwin x64 baseline builds and tests
.buildkite/ci.mjs, scripts/build/deps/webkit.ts
Darwin x64 build and test matrix entries now use baseline: true, and WebKit comments document x64-only baseline artifacts and suffix ordering.

Possibly related issues

  • oven-sh/bun#34206 — Adds the missing Darwin x64 baseline CI lanes and updates WebKit baseline-artifact documentation.

Suggested reviewers: robobun, dylan-conway, jarred-sumner

🚥 Pre-merge checks | ✅ 4
✅ Passed checks (4 passed)
Check name Status Explanation
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.
Title check ✅ Passed The title is concise and accurately summarizes the main change: adding a real darwin-x64 baseline build.
Description check ✅ Passed The description includes the PR purpose and verification details, though it uses different headings than the template.

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In @.buildkite/ci.mjs:
- Line 140: Gate or disable the darwin x64 baseline configuration in the CI
matrix until the pinned WebKit release provides the required baseline tarballs.
Update the entry identified by os "darwin", arch "x64", and baseline true, while
preserving the non-baseline darwin x64 lane.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 9b41694a-4eb5-47d3-b2f6-b0b4eaf1e529

📥 Commits

Reviewing files that changed from the base of the PR and between b69e3ca and 6c2f80f.

📒 Files selected for processing (2)
  • .buildkite/ci.mjs
  • scripts/build/deps/webkit.ts

Comment thread .buildkite/ci.mjs
// these are the darwin artifacts the release ships.
{ os: "darwin", arch: "aarch64", crossCompile: true, distro: "amazonlinux", release: "2023", features: ["docker"] },
{ os: "darwin", arch: "x64", crossCompile: true, distro: "amazonlinux", release: "2023", features: ["docker"] },
{ os: "darwin", arch: "x64", baseline: true, crossCompile: true, distro: "amazonlinux", release: "2023", features: ["docker"] },

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Map the relevant file and surrounding symbols
ast-grep outline .buildkite/ci.mjs --view expanded || true

# Show the relevant section with line numbers
sed -n '120,220p' .buildkite/ci.mjs | cat -n

# Find WebKit pin / artifact naming logic
rg -n "baseline|baseline-LTO|bun-darwin-x64-baseline|webkit|artifact|triplet|crossCompile" .buildkite/ci.mjs

Repository: oven-sh/bun

Length of output: 14910


🏁 Script executed:

#!/bin/bash
set -euo pipefail

# Inspect the file that defines the platform matrix and any related WebKit pin configuration.
git ls-files | rg '(^|/)\.buildkite/ci\.mjs$|webkit|WebKit|baseline|triplet|artifacts|bun-darwin'

Repository: oven-sh/bun

Length of output: 1440


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== .buildkite/ci.mjs excerpt =="
sed -n '130,210p' .buildkite/ci.mjs | cat -n

echo
echo "== references =="
rg -n "baseline|baseline-LTO|bun-darwin-x64-baseline|triplet|webkit|artifact" .buildkite/ci.mjs

Repository: oven-sh/bun

Length of output: 11124


🌐 Web query:

Bun WebKit baseline artifact bun-darwin-x64-baseline baseline-LTO WebKit autobuild

💡 Result:

The bun-darwin-x64-baseline artifact in Bun is intended to provide a version of the Bun runtime compatible with older Intel processors (pre-Haswell, such as Ivy Bridge) that lack support for advanced instruction sets like AVX2 and BMI2 [1][2]. However, historically, this artifact has faced technical issues regarding its WebKit dependency. Because Bun relies on a prebuilt WebKit library, a true "baseline" macOS x64 binary requires that the linked WebKit library also be compiled for a baseline CPU target (e.g., -march=nehalem) [3][4]. In the past, the bun-darwin-x64-baseline artifact was often incorrectly linked against the standard "modern" macOS WebKit (which includes BMI2 instructions like shlx), causing the Bun binary to crash with an SIGILL (Illegal Instruction) error upon launch on older CPUs [3][1]. Key points regarding these artifacts include: * Architecture Compatibility: The standard Bun binary requires AVX2 support [2]. The -baseline suffix signifies a build intended for CPUs that lack these instructions [2]. * WebKit Linking: Bun's build system uses specific suffixes (such as -baseline, -lto, or -musl) to select the appropriate prebuilt WebKit artifact [4][5]. For Linux and Windows x64, dedicated baseline WebKit artifacts exist [4]. For macOS, the lack of a corresponding baseline WebKit artifact has previously led to the bun-darwin-x64-baseline binary essentially acting as a non-baseline build, which can trigger crashes on unsupported hardware [3][6]. * Build System Enforcement: To prevent the distribution of misleading artifacts, the Bun build system has been updated to reject the creation of macOS "baseline" binaries unless a genuinely compatible baseline WebKit artifact is available [3]. * LTO (Link Time Optimization): The baseline-LTO terminology refers to a configuration that combines the baseline CPU target requirements with Link Time Optimization for performance. WebKit artifacts are often built with either LTO or debug symbols, and the build system ensures the suffix matches the artifact to avoid linking mismatches [4][5]. As of recent updates, the development team has been working on introducing specific baseline macOS WebKit lanes to properly resolve these crashes and provide a functional baseline experience for older macOS hardware [6].

Citations:


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== scripts/build/deps/webkit.ts outline =="
ast-grep outline scripts/build/deps/webkit.ts --view expanded || true

echo
echo "== relevant webkit.ts lines =="
rg -n "baseline|LTO|artifact|darwin|macOS|webkit" scripts/build/deps/webkit.ts

echo
echo "== SetupWebKit.cmake lines =="
fd -a 'SetupWebKit.cmake' . || true

Repository: oven-sh/bun

Length of output: 3058


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== package README excerpts =="
sed -n '1,220p' packages/bun-release/npm/@oven/bun-darwin-x64-baseline/README.md | cat -n
echo
sed -n '1,220p' packages/bun-release/npm/@oven/bun-darwin-x64/README.md | cat -n

echo
echo "== baseline package references =="
rg -n "bun-darwin-x64-baseline|baseline-LTO|WebKit" packages/bun-release/npm/@oven/bun-darwin-x64-baseline packages/bun-release/npm/@oven/bun-darwin-x64

Repository: oven-sh/bun

Length of output: 612


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== scripts/build/deps/webkit.ts relevant section =="
sed -n '1,260p' scripts/build/deps/webkit.ts | cat -n

echo
echo "== any baseline-specific references in webkit setup =="
rg -n "baseline|LTO|artifact|download|prebuilt|darwin|x64" scripts/build/deps/webkit.ts

Repository: oven-sh/bun

Length of output: 16062


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== SetupWebKit.cmake and related files =="
fd -a 'SetupWebKit.cmake' .
fd -a 'WebKit.cmake' .
fd -a 'webkit' cmake scripts | sed -n '1,200p'

echo
echo "== package and docs references to darwin x64 baseline =="
rg -n "bun-darwin-x64-baseline|baseline-LTO|WebKit" packages docs scripts cmake .claude -g '!**/node_modules/**'

Repository: oven-sh/bun

Length of output: 34822


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== scripts/build/config.ts relevant baseline/lto section =="
sed -n '730,790p' scripts/build/config.ts | cat -n

echo
echo "== scripts/build/profiles.ts relevant release/profile section =="
sed -n '130,170p' scripts/build/profiles.ts | cat -n

echo
echo "== scripts/build/deps/webkit.ts prebuilt and build usage =="
sed -n '188,430p' scripts/build/deps/webkit.ts | cat -n

Repository: oven-sh/bun

Length of output: 18811


🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== test/build lane construction around baseline =="
sed -n '740,840p' .buildkite/ci.mjs | cat -n

echo
echo "== release step / artifact selection hints =="
sed -n '1040,1075p' .buildkite/ci.mjs | cat -n

echo
echo "== build step generation around triplets and prebuilt webkit =="
sed -n '540,700p' .buildkite/ci.mjs | cat -n

Repository: oven-sh/bun

Length of output: 14080


🏁 Script executed:

#!/bin/bash
set -euo pipefail

tag="autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b"

echo "== release =="
gh api "repos/oven-sh/WebKit/releases/tags/${tag}" --jq '.tag_name, .name, .assets[].name' || true

echo
echo "== matching asset names =="
gh api "repos/oven-sh/WebKit/releases/tags/${tag}" --jq '.assets[].name' | rg 'bun-webkit-macos-amd64(-baseline)?(-lto)?\.tar\.gz|bun-webkit-macos-arm64'

Repository: oven-sh/bun

Length of output: 2123


🏁 Script executed:

#!/bin/bash
set -euo pipefail

tag="autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b"

gh api "repos/oven-sh/WebKit/releases/tags/${tag}" --jq '.assets[].name' | sort

Repository: oven-sh/bun

Length of output: 1739


Gate the darwin x64 baseline lanes until the matching WebKit tarball lands. The pinned autobuild-4895f45dfbd0d1226c4d41799887bc0ecb9f341b release only has bun-webkit-macos-amd64.tar.gz and bun-webkit-macos-amd64-lto.tar.gz; it does not publish bun-webkit-macos-amd64-baseline.tar.gz or bun-webkit-macos-amd64-baseline-lto.tar.gz, so the build will fail when fetching WebKit.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.buildkite/ci.mjs at line 140, Gate or disable the darwin x64 baseline
configuration in the CI matrix until the pinned WebKit release provides the
required baseline tarballs. Update the entry identified by os "darwin", arch
"x64", and baseline true, while preserving the non-baseline darwin x64 lane.

@tobocop2

Copy link
Copy Markdown
Author

Closing this. bun main solved the problem a different way.

Baseline is the default now. config.ts sets baseline = x64, "the only x64 build we ship". buildPlatforms has no baseline: true entries left. darwin-x64 is already a nehalem build, so the lane this PR adds is unnecessary.

The suffix is gone. prebuiltSuffix() no longer adds -baseline. WebKit builds one x64 artifact per platform at the nehalem floor (oven-sh/WebKit@541f498e), so no -baseline tarball exists to request. My change here does the opposite of what main does.

oven-sh/WebKit#290 is closed for the same reason.

One fix is still open: oven-sh/WebKit#292. JSC assumes AVX on macOS. The probe trampoline emits vmovaps. Macs with no AVX at all, Westmere and older, still crash at tier-up. Sandy Bridge and Ivy Bridge have AVX, so they are safe.

No release carries the nehalem change yet. bun v1.3.14 is from May. The WebKit commit is from July.

@tobocop2 tobocop2 closed this Aug 19, 2026
@genose

genose commented Aug 19, 2026

Copy link
Copy Markdown

@Jarred-Sumner @dylan-conway @cirospaciari @alii — can this be unblocked?

This PR is the direct fix for non-AVX CPU support on macOS — a regression that has been open since v1.3.9 (nearly a year). The missing darwin baseline build lane means @oven/bun-darwin-x64-baseline has been silently shipping the same AVX2 binary as the standard build, making the baseline package effectively useless on macOS.

The dependency (oven-sh/WebKit#290) is verified and complete. Once that merges, this PR is ready to go.

Impact:

The fix is done. Please merge.

I'd also love to contribute directly — if there's an opportunity to join the team or help push non-AVX support forward, I'm available.

— @genose

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Illegal Instruction in macOS intel without AVX2 bun-darwin-x64-baseline crashes with SIGILL on Ivy Bridge CPUs due to BMI2 instructions

4 participants